OSI STRATEGY PRESENTATION Picture 1. International Standards In a world where the economy is becoming increasingly global, communications is the key to competitiveness. Businesses require extensive, timely and accurate information exchange. Vast amounts of data need to be processed, formatted and transferred across departmental barriers, corporate entities and even international frontiers. No single vendor of computer equipment can meet the needs of the entire marketplace. Thus, a computer and communications user need to "mix and match" components from several suppliers to effectively distribute applications across multiple platforms. This diversity of equipment quickly generates a need for standardized communications networks as users face the reality of incompatible hardware and software from a multitude of sources. Standardized networks can take any of three forms; dependence on a single vendor, if a proprietary networking solution is chosen throughout the system, implementations of de facto standards, or true multivendor networking based on international standards. In the first case, the supplier with the largest installed base will benefit handsomely, while other suppliers are forced to follow suit. In the second case, a middle ground is chosen, but typically only some suppliers will be able to provide adequate product offerings, and possess the necessary skills to configure, maintain and grow the network as business expands. In the third case internationally agreed upon standards form the framework of the communications backbone. This is the Open Systems Interconnect (OSI) case, the use of internationally agreed upon standards for multivendor networking. What does OSI offer its users? Consider the following example; Five organizations interact in a global marketplace; a manufacturer of finished goods, a distribution center, a sales outlet, a supplier of raw materials, and a financial institution. The manufacturing company has recently developed a new product, XYZ, and is now actively seeking customers across the world. Picture 2. Intercompany Communications Today The sales outlet receives a request for product information from one of its customers. Some of the desired information is immediately available, but a key component is lacking; the new pricing structure. A request for pricing information is sent off to the manufacturing entity, asking for an update. The manufacturing company stores product information in a central database; a huge file with new prices, options and quantity discounts. In response to the request from the sales office, this information is dispatched over the corporate OSI network, using the OSI File Transfer, Access and Management protocol, FTAM. The manufacturing company decides to make sure sufficient quantities of product XYZ can be made available to the sales office to meet the expected demand. It sends a query off to the local distribution center, asking how much of product XYZ, option ABC is available. The distribution center responds via electronic mail. For this simple exchange, no file transfers need occur. A basic store and forward mechanism for data exchange is sufficient. The applicable OSI service is the CCITT X.400 set of protocols. Assuming the distribution center does not have sufficient quantities of the product in stock, the manufacturing company decides to make additional quantities to meet the expected demand. Raw materials need to be ordered from a supplier and shipped to a production center. Orders have to be generated, bills of material need filling out, and invoices must be paid. Ordering and invoicing are considerably more complex tasks than file transfer or electronic messaging. Basic OSI services need to be supplemented by additional functionality to handle business applications of this kind. This additional functionality is provided by a translation service called Electronic Data Interchange, EDI. An EDI translator uses X.400 as its transport mechanism. There is now a UN standard called Electronic Data Interchange For Administration, Commerce and Trade, EDIFACT, which is rapidly being deployed around the world. EDIFACT not only formats data. It also includes facilities for copying messages to multiple locations. This is typically used for providing banks with the transaction data necessary to complete the financial portion of a deal. When a bank receives EDI information, it will extract the applicable data and transfer the correct funds from one account to another. Today, OSI does not have a specific protocol that would simplify processing of financial transactions such as this. The final step in this business example would thus be handled by proprietary or de facto standard network protocols. As will be shown later in this presentation, future OSI protocols will soon address this need. Picture 3. Intracompany Communications Today OSI services are useful not only between remote locations, over wide area networks, or WANs, but are also highly applicable within a manufacturing entity. Expanding the example above to include intracompany communications within a production center, the following scenario evolves; A plant floor operator receives an X.400 message, stating that a production run needs to be made of product XYZ, with options ABC and in quantity N. The operator will transfer job data, specifying the what, when and where's to a production cell controller. As this would typically be in the form of a set of instructions, arranged in a file, FTAM would be the applicable OSI protocol. The cell controller downloads instructions to the factory floor equipment. These instructions are real-time commands, such as start, stop, open, close etc. OSI provides a generic set of semantics for communications between intelligent factory floor devices. More than eighty specific commands are included in the OSI Manufacturing Messaging Specification, MMS, used for shop floor control applications. MMS commands also enable upload of data, from programmable logic controllers, PLCs, or numerical controllers, NCs, on either a continuous basis, or in response to alarm triggers. In certain cases, such as large production cell, a large number of intelligent devices are interconnected. For the cell controller to find the correct device, a directory service may be a necessary addition. OSI provides this functionality through the use of the OSI Directory Services protocol, X.500. Once the production run is finished, a bill of material is sent to the scheduling computer, the area manager. Since the amount of data to be transferred is likely to be large, the OSI file transfer protocol, FTAM, will again be the most applicable service to use. If an insufficient quantity has been produced, or additional demand has materialized, the Area Manager may decide to initiate a new production run. For this purpose, more raw material will be needed, and an EDIFACT message will be sent to the supplier, commencing a new production cycle. Picture 4 - 5. Coming OSI Services The OSI Directory Services specification to be used in conjunction with the electronic mail service has recently become an International Standard, or IS. Electronic Mail users will thus be able to add X.500 to their existing X.400 services. This will make implementations of large scale X.400 backbones a valid proposition. In addition, OSI protocols to handle transaction processing will soon become available. This will enable the bank in the example above to use OSI Transaction Processing, TP, for the transfer of funds, rather than proprietary or de facto transfer mechanisms. OSI is also adding functionality to the factory floor applications environment. The OSI Virtual Terminal protocol enables operators to better monitor the operations, and to address certain output from the process to, for example, slaved printers. The MMS protocol is being enhanced through the addition of a range of companion standards. These additions initially include commands that are specific to the operation of programmable logic controllers, numerical controllers and robots. Picture 6. Technology Trends As shown in the example above, OSI provides a wide range of functionality, applicable to various areas of business. In fact, OSI today encompasses more than 80 different standards, that can be combined into so called profiles. Profiles address specific needs of an industry, or an application environment and specify a given subset of the wide range of OSI services. Through mandatory profiles, OSI is rapidly becoming THE multivendor protocol, surpassing de facto standards such as TCP/IP or NetBIOS in functionality and versatility. Other de facto standards, such as DECnet and SNA offer additional functionality, but are considerably less multivendor than OSI. The multivendor aspect of DECnet, as well as that of SNA, is now being addressed through the gradual incorporation of OSI services into the two proprietary architectures. OSI is rapidly moving in two directions; towards increased functionality and towards increased multivendor connectivity. More and more companies endorse and adopt OSI standards as the basis for their communications architectures. More and more protocols are added to already existing OSI standards, extending its usefulness to more and more application environments. Picture 7. OSI Deployment User acceptance of OSI varies around the world. In Europe, one company in three is now implementing OSI. Close to another one in three is committed to implementing OSI in the near future. An additional one in four is seriously interested in OSI. In the US, only one company in ten is currently implementing OSI. Twice that amount is committed to OSI, and one company in three declares an interested in OSI. Adding the implementing, committed and interested segments together, approximately 60% of US respondents in a recent Yankee Group survey fall into this new segment. The situation is similar in Europe, although the trend towards implementation is more pronounced. What we are experiencing is a time lag. The US market is lagging the European market in the adoption of OSI standards. Currently this time lag is in the range of one to two years. Picture 8. Government OSI Profiles. The time lag can largely be explained by looking at the introduction dates of mandatory Government OSI profiles. In the UK, OSI networking protocols became a mandatory requirement for government information technology purchases as early as in January 1989. Sweden followed suit in April 1989. Other Nordic countries made the same decision later the same year. In the US, a Government OSI Profile is in force as of August 1990, a full year and a half year behind the UK. Based on current maturity of OSI protocol standards, and the availability of OSI based products, the US can be expected to close this gap in the near future. OSI is now poised for growth, on both sides of the Atlantic. It is also worth noting that GOSIPs typically include more than just a subset of OSI standards. A typical GOSIP is divided into four sections, a T-subprofile, an A-subprofile, an F-subprofile and a C-subprofile. The T-subprofile, for Transport, specifies OSI protocols to be used for media access, internet routing and transport. The A-subprofile, for Application, specifies the upper layers of the protocol stack, from the session layer to the application layer. The F-subprofile, for Formats, extends the specification outside of the basic OSI protocols, into the area of data exchange. Here, the Electronic Data Interchange, EDI, format is specified, as is the Office Document Architecture, ODA. The C-subprofile, for Characters, deals with regional character subsets, to correspond to the various languages that have to be supported by implementations of OSI. The inclusion of format standards have considerably added to the momentum of OSI deployment. OSI based EDI implementations are currently experiencing triple digit growth in most industrialized nations. Picture 9. OSI Evolution OSI will not become THE multivendor standard overnight. A long period of transition from currently used de facto standards, to the de jure OSI Standards, can be expected. There are four basic phases of this transition; pilot implementations, subnetworks based on OSI and a long coexistence phase before the ultimate dominance of OSI comes about. In the pilot phase, the typical user will require a simple platform onto which he can port a distributed application. The user will install OSI in a controlled environment, isolated from the operational backbone of his organization. The pilot will serve as a knowledge build-up basis for the application developer. In the second phase, applications based on OSI emerge. The former pilots become integrated with the corporate backbone, but handles specific tasks. Which tasks will be chosen are typically based on which unique OSI functionality has driven the pilot to success. To preserve the existing de facto standards based backbone, dual or parallel protocol stacks need be part of the target applications platform. During the long coexistence phase, it is expected that OSI will gradually overtake the deployment and use of de facto standards. New applications will use OSI network protocols, older applications are likely to stay with de facto standards. Their peaceful coexistence is assured by the fact that output messages, from the dual stack machines, can be transferred over a common link. When application integration become necessary between heterogeneous networking environments, application layer gateways can be used. At a lower level, multiprotocol routers enable OSI and de facto standards to share a common media. Standards exist for both the first two approaches, and products have been entering the marketplace since early 1990. If distributed applications need share a common link and media, but in a single vendor environment so called tunneling may be a temporary solution. Tunneling provides the possibility to encapsulate messages based on one networking standard, into frames sent by another networking standard. As no standards for this approach exist, the multivendor connectivity benefit of OSI will be lost when proprietary tunneling techniques are used. Picture 10. Multivendor Applications are the Future OSI is rapidly becoming a commonly used base for multivendor applications. The various OSI profiles specify a wide range of links, transport options and application layer services. A multitude of business applications make use of OSI file transfer services, store and forward messaging mechanisms, generic semantics for factory floor communications and directory services. In a truly distributed applications environment, additional services are needed. In the area of Information Exchange, standardized information structures are necessary additions. Electronic Data Interchange, EDI, standards such as the UN sanctioned EDIFACT provide a de jure standard for order and invoicing applications. The Office Document Architecture information structure provides de jure standards for compound document transfers. Information exchanges are also aided by additional services for virtual terminal support, VTP, and graphics transfer, CGMIF/GKS. Distributed processing is another area where additions to the existing OSI networking base is necessary. Emerging standards, such as OSI Remote Data Base Access, RDA; Transaction Processing, TP; and On Line Data Processing, ODP, will enable a whole new range of distributed applications to become deployed. In addition, de jure standards exist for the crucial task of Network Management. As networks grow in complexity, the need for accurate and efficient network management rises in proportion. The CMIS/CMIP set of network management protocols has been designed specifically with this in mind. Picture 11. Applications Environments Current deployment of OSI networks is closely linked to certain application integration environments. Based on the availability of OSI links, transport mechanisms and services, software developers are beginning to develop off-the-shelf distributed applications. Most of these applications are ported from existing, de facto standard, network environments and are highly customized for the intended end user. Other applications are developed from scratch, making use of unique functionality offered by the OSI services. These applications are primarily based on the X.400 store and forward mechanism or on the Manufacturing Messaging Specification, MMS. Neither of these services has direct equivalents in the de facto standards based networks installed in the past. Emerging application areas are to be found among telecommunications and utility organizations, and in the vast service sector. In the first category, Network Surveillance is the key application. In the service sector, transaction processing applications predominate. Airline and Hotel reservations systems abound, as do car rental reservation systems and, of course, automatic teller machines. Picture 12 - 18. Applications Integration To make use of OSI network functionality, an application developer need not necessarily know the insides of each service provided. Several of the OSI services are rich in functionality, and their complexity may divert a developer from using an optimized approach. Recognizing this fact, major vendors of OSI development platforms are now focusing their efforts on application programming interfaces, or APIs. These interfaces are intended as an aid to the application developer, providing access to underlying services, but in a comprehensive format. Like the services they interact with, the APIs are often standardized to allow porting of applications between development platforms. In general, there is an API available for each OSI service commonly implemented. For the X.400 service, a vendor organization called the API-Association has defined a series of programmatic calls that simplify the development of electronic mail gateways. Based on the API-A X.400 API, high level APIs have been developed to cover other application areas where store and forward messaging is required. Electronic Data Interchange is the most commonly addressed information structure. The Office Document Architecture, or ODA information structure is another high growth area among software developers. Other existing APIs are those specified by the MAP/TOP Users Groups, such as the FTAM User Interface and the MMS-I specification. The MMS-I, in particular, is an often used API for the integration of factory floor applications. Based on these generally available specifications, many developers of Real-time Monitoring and Control software packages are now adding OSI to their list of network protocol options. In the highly developed European markets, APIs that allow easy access to intermediate layers of the seven layer OSI model are frequently used when porting older applications into an OSI environment. These APIs primarily address the need for access to the transport level of the OSI protocol stack. the most common Transport level API is the X/TI, defined by the X/Open group of companies. Other APIs to intermediate levels are mainly derived from the CCITT access libraries. Emerging APIs address the need for easy access to the OSI directory services, X.500 and to the network management protocol suites, CMIS/CMIP. Future APIs are focused on the transaction processing protocols. A developer using OSI will need a basic subset of the OSI protocol stack, more often than not combining this subset with additional information structures. In addition the developer will need diagnostics and maintenance tools. Perhaps he will even require expert systems for nodal and network troubleshooting, tracing/logging control and formatting, and statistics for fault isolation and performance tuning. These are all tools available from major vendors of OSI development platforms, usually free of charge when a basic service is purchased. Picture 19 - 20. Conformance and Interoperability To be truly multivendor, applications using OSI products, must be sure that the services, transport mechanisms and links conform to the existing standards. Conformance to a given profile, or part thereof, can be tested at designated test centers throughout the world. Non-profit organizations such as the Corporation for Open Systems, COS, in the United States, or the Standards Promotion Agency, SPAG, in Europe are recognized test centers for their respective markets. For the Japanese market, INTAP provides a similar service. In addition, a few vendors of OSI products have become accredited by such test centers, and have in-house testing capabilities to aid in their development efforts. At the time of writing, Bull HN Information Systems Inc. and Hewlett-Packard Company are the only COS accredited test centers in the US. Conforming to a standard does not guarantee interoperability, however. There are various ways an OSI protocol can be implemented, and numerous options to the basic services may or may not be included in an OSI product. Interoperability is the key to the distributed applications environment, and should be demonstrated by an OSI vendor upon request. Many vendors have long had interoperability testing programs in place. By linking systems via OSInet, EurOSInet, OSIcom and related organizations' networks, vendors can easily test their respective product offerings for interoperability. In addition, major trade shows often feature OSI LAN and WAN interoperability as a key topic of the demonstrations provided. Picture 21 - 24. HP OSI Products Hewlett-Packard offering of OSI products is divided into four groups, Application Programming Interfaces, Basic Protocols and Services, Links Level Products and Instruments. The APIs are application developers tools and, like the OSI services, based on standards. The MMS-I and FTAM-UI provide functionality as per the Manufacturing Automation Protocol, MAP 3.0. The X.400 API is a high level API based on the API-A specification. In contrast to the full API-A specification, HP's high level X.400 API is not intended for development of Electronic Mail gateways. Rather, it provides specific functionality for developers of additional applications using the X.400 messaging services. These applications include Electronic Data Interchange and Office Document Architecture translators. APIs also exist to intermediate layers of the OSI protocol stack. The X/OPEN Transport Interface, X/TI, is provided for developers needing direct access to the OSI Transport layer, bypassing the above layers five through seven. The CCITT access libraries are used to provide access directly to layer five, the Session layer. Currently, HP provides four service products. For Shop Floor Control applications, MMS and FTAM are provided. For Electronic Mail, HP offer X.400. A basic protocol stack, Open Transport Services, provide the intermediate layers. The services can be used over a variety of link level products, including IEEE 8802.4 Token Bus, IEEE 8802.3 CSMA/CD and CCITT X.25. A instrument for developers of Shop Floor Control applications is also provided, in the form of the HP MAP 3.0 protocol Analyzer. Together, these products enable MIS departments, Independent Software Vendors and Systems Integrators to develop applications in the areas of Shop Floor Control, Electronic Mail, Electronic Data Interchange or to develop customized applications for specific environments. Future products will be rolled out on HP-UX, MPE and Domain operating systems. These products, including new services such as VTP, CMIS/CMIP, TP and others will enable development of applications in Network Surveillance environments and in Transaction Processing environments. Picture 25. Integrated Applications Based on the Services and related APIs described above, a range of applications have today been ported to, or developed for, HP OSI networking environments. For Electronic Mail, HP has its in-house developed OpenMail application. KeyPak, from Keyword Office Technologies can be used with HP Open Mail, and will then add formating according to Office Document Architecture, ODA, specifications. Electronic Data Interchange, EDI, translators conforming to the UN specified EDIFACT standard are provided by Kaakontieto and SAP, respectively. As is the case for E-Mail applications, EDI uses X.400 messaging over LAN and WAN links. For Shop Floor Control, six companies have added applications to the basic OSI services. US based GE Fanuc, Hilco and US Data provide Control packages containing real-time graphics, trending, logging and databases. In Europe, Marex and MCII provide similar functionality with their respective applications. For connections to Siemens Programmable Logic Controllers, Siemens itself is using HP OSI products to incorporate OSI into its SINEC communications architecture. Additional applications are being added on a continuing basis. Picture 26. Summary Hewlett-Packard is today a leading provider of OSI products. Seven years into its OSI program, HP provides a wide range of OSI links, services and application programming interfaces. A broad range of computer platforms, running HP-UX as well as MPE operating systems support these protocols. HP OSI products conform to Government OSI Profiles, MAP/TOP and other profiles across the world. Interoperability with other vendors is assured through continous testing, in-house as well as through independent organizations and at trade shows around the world. HP's OSI customer base is now well into triple digits. Major organizations are using HP OSI products for vital business applications such as Funds Transfer, Electronic Mail, Monitoring and Control of power distribution systems, Shop Floor Monitoring and Control, Electronic Data Interchange and more. What really makes HP different from other vendors of OSI products is more than just products. The HP OSI offering is combined into application development platforms, targeted at specific business environments. Independent Software Developers, ISV, Original Equipment Manufacturers, OEM, and Systems Integrators have ported or developed applications to the HP OSI environment. Business applications available today include Shop Floor Control Packages, Electronic Mail packages, Electronic Data Interchange translators and Office Document Architecture formatters. More applications are being added on a continuing basis. The applications developers can make use of a broad range of development tools, many of which are unique to HP, and which greatly enhances productivity at the development site as well as at the actual deployment site.